…store

## Summary

### Why?

Integrating speculation needs the controllers to answer "which build belongs to this path" in both directions, without ever looking a row up by non-key attribute — the storage contract stays get/put-by-key so any KV backend can satisfy it. The build system mints its own build identifiers, and those stay the build store's primary key: the runner's ID is the natural name for the build row. What's missing is a durable link between a tree path and its build that exists independent of any in-flight message, plus a well-defined path identity to hang that link on.

### What?

`entity.SpeculationPathInfo` gains `ID` — an assigned, immutable path identity, unique within its tree, minted by the speculate controller when it creates the tree (so it exists before any build is triggered and survives crashes). `entity.SpeculationPathBuild` is the new mapping entity ({PathID, BuildID, BatchID, Version, CreatedAt}, named after its `speculation_path_build` table) with a `SpeculationPathBuildStore` (Create/Get keyed by PathID): the forward path→build lookup, written only by the build controller, at most one build per path with ErrAlreadyExists making the existing row the truth on races. BatchID makes the row self-describing without parsing PathID's format; Version follows the repo's optimistic-locking convention (write-once today, reserved for future conditional re-pointing flows). `entity.Build` keeps the runner-minted `ID` as its primary key and gains `SpeculationPathID` as a plain column — the reverse build→path lookup; the previously embedded `SpeculationPath` value is dropped as a redundant denormalized copy of what the tree already stores. `SpeculationPath.Equal` (order-sensitive Base + Head) provides structural path identity for decision matching. `entity.QueueID` with ToBytes/QueueIDFromBytes mirrors the BatchID payload pattern for queue-scoped stages.

MySQL gains the `speculation_path_build` table and the build table swaps `speculation_path`/`runner_id` for `speculation_path_id`; schema files are picked up automatically (the schema dir is globbed by both Bazel and the testutil ApplySchema helper).

## Test Plan

✅ `make gazelle && make fmt && make test` (74/74). ✅ `bazel test //test/integration/submitqueue/extension/storage/...` against real Docker MySQL: Build round-trip with runner-style ID + SpeculationPathID, SpeculationPathBuild Create/Get round-trip incl. BatchID and Version, duplicate Create → ErrAlreadyExists, missing Get → ErrNotFound. Unit tables cover SpeculationPath.Equal and entity serialization incl. the new fields.